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1. INTRODUCTION 



The methods described here have been developed to assist in 
the timely control, and economic use of a nationwide bulk delivery fleet 
of petroleum tank trucks. This portion of the system is intended to 
aid dispatchers by correlating large amounts of data in real time and 
producing nearly complete shift dispatches for each bulk terminal 
from which loads are hauled. The dispatchers, located at a central 
national order processing facility, must each handle several bulk 
terminals as well as coordinate other activities related to product 
availability, order entry, non-proprietary equipment requirements, and 
(recently) allocation. 

Fundamental to the philosophy of the system is that the human 
dispatcher cannot be replaced. Rather, he must be materially assisted 
in his work by quick and comprehensive presentation of dispatch information 
in concise terms, with identification of exceptional conditions requiring 
manual intervention. The dispatcher is expected to make whatever adjustments 
are necessary while preserving the overall quality of the dispatch. 

Very strict computer performance criteria must be met by the 
system. Even the largest dispatch should not require more than a fraction 
of a second of computer time or more than a very small memory region. 

This efficiency (as well as reliability) is vital to the effective use of 
the system as an integrated transaction module in a real time information 
management system on a congested host computer. Daily operations require 
hundreds of trial dispatches during a very short time period, although this 
is mitigated somewhat by time zone differences across the continent. 
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The system is intended to reduce operating costs in several ways 
[3]. It controls overtime (and undertime) for vehicles and drivers, helps 
reduce costly human errors, and uses the most economic available means of 
transportation. Indirect objectives include greater manpower utilization 
system-wide, equitable distribution of workload, and other benefits 
enumerated later. 

The overall system can be viewed as processing, maintaining and 
displaying for each bulk terminal a large volume of information concerning 
the bulk terminal area, customer orders, and vehicles. These data are 
used to produce in a timely manner two shift dispatches per day for each 
terminal. Each dispatch must satisfy many explicit specifications of 
customer delivery times and mileages, special equipment requirements, 
product-specific capacities of each vehicle compartment, delivery time 
restrictions, and so forth. The dispatcher must also consider myriad 
implicit conditions such as rush hour traffic congestion, local road and 
weather conditions, adjustment limits on ordered quantities to suit avail- 
able vehicle compartments, etc. 

In the sections that follow, basic elements of the problem are 
introduced in sufficient detail to motivate key design decisions, an over- 
all solution scheme is proposed for the dispatch process, an integer 
linear program is proposed for the principal dispatch module, and 
implementation and system use are described. A concluding discussion con- 
siders what should, and what should not, be automated in the dispatch system. 
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2. ELEMENTS OF THE PROBLEM 



In this section, the basic elements of the dispatch problem are 
introduced in the context of daily operations. There is necessarily much 
simplification. However, the complex environment within which the dispatch 
function is embedded is both technically and organizationally relevent to 
the solution methods introduced later. 

Bulk Terminals 

Each bulk terminal acts as a storage point for as many as 16 
products ranging from weed oil to jet fuel, but dominated in terms of sheer 
volume by motor gasoline. Product is received by pipeline, barge or truck, 
stored in tanks, and transferred to delivery vehicles via drive- through 
loading racks. Drivers are domiciled with company owned vehicles at the 
terminal, with collocated service facilities for vehicle maintenance. 

Figure 1 shows the location of terminals for this system. 

Before implementation of the new centralized system, each terminal 
had a dispatcher who manually performed the local daily dispatch, assisted 
by other terminal personnel, often the drivers themselves. Reorganization 
for the new system has relocated this dispatch function to the central 
nationwide facility and significantly increased the responsibilities and 
workload to include several bulk terminals. Meanwhile, local dispatch 
assistants have been returned to their primary duties. 

Delivery Vehicles 

Delivery vehicles possess a wide variety of features relevant to 
their use in the dispatch. For illustrative purposes, a model truck and 
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FIGURE 1, BULK TERMINALS 



trailer rig (see Fig. 2) is equipped with multiple isolated compartments. 
Each compartment has a volumetric capacity specific to the density of 
the product contained. Material loading is accomplished at the bulk 
terminal from top or bottom outlets at a loading rack. Customer delivery 
is generally made by gravity feed with a valve manifold connecting the 
compartment via a hose to an underground storage tank; the entire content of 
the compartment is dropped, necessitating careful prior determination of 
available storage tank capability to preclude accidental spills. 

The variation of this basic vehicle design are myriad. They 
result from local vehicle laws, geographical and temporal demand patterns, 
and historical management policy. Each vehicle may have from 1 to 6 
compartments, special fittings, meters and pumps, manifolding which 
prevents cross-product contamination (e.g., lead) upon delivery, vapor 
recovery gear, and so forth. Also, each vehicle must be loaded in 
accordance with its weight limits, those of road jurisdictions to be 
traversed, and such that compartments empty, or not fully loaded, satisfy 
a complicated specification arising from safe road handling considerations. 

Vehicle operating costs are specified for proprietary trucks 
on a customer-by-customer basis as a function of mileage and standard 
delivery time; proprietary trucks are classified in several cost 
categories for this purpose. Non-proprietary truck costs may also be 
simple functions of actual delivery time and mileage, or may be fixed 
point-to-point charges for each trip depending upon operating region 
and contract terms and duration; several categories of non-proprietary 
trucks are used in any given bulk terminal. 
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FIGURE 2. DELIVERY VEHICLE 



Each vehicle is assigned a sequence of loads for a shift with 
the duration of each shift determined by driver availability, vehicle 
availability, and contract terms. Overextension of vehicle shifts leads 
to overtime labor costs, disrupts following shifts, and can foment 
employee dissatisfaction. Underutilization of vehicles causes other 
similarly unfortunate outcomes, the most obvious being economic. 

Historically, the local manual dispatcher has not considered 
operating costs in any detail. That is, he may have had a crude rule of 
thumb that a particular vehicle should be cheaper to operate for certain 
deliveries, but he certainly had no time to actually compute alternate 
delivery costs, let alone consider overall fleet allocation among 
deliveries. An examination of dispatch histories revealed many opportunities 
for significant savings, providing further motive to develop a new 
system with the capability to reduce costs as well as assist the dispatcher. 



Customer Orders 

Each customer order is received by telephone. In the past, the 
local terminal took the call, manually processed all paperwork, and arranged 
for delivery. Now the call is handled by the nationwide dispatch facility, 
where an order processor immediately retrieves on a display console the 
customer’s order file. Each order typically includes three products, 
usually grades of gasoline, jointly constituting a complete truck load. 
Following credit and allocation releases and other preliminaries, the 
order is entered into the information management system with the desired 
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quantities of each product, the target delivery, date arid shift (s), and 
additional data regarding special equipment requirements (such as special 
couplings, pumps, an unmarked truck, and so forth), driver instructions, 
and billing data. 

The entire order entry process requires at most a couple of minutes, 
averaging 30 seconds. Further, customer service is now significantly 
enhanced by the dependable availability of an order processor and new capa- 
bilities to, for instance, trace orders. Also, uniform control of the 
order processing function is desirable, if only from the standpoint of 
the thousands of dollars represented in each transaction. 

Orders are accumulated throughout the day for future delivery. 
However, a cutoff time is specified after which no order is accepted for 
delivery on the following day. Soon after the cutoff time, a dispatcher 
extracts on his display console all the orders to be satisfied, assesses 
equipment and driver availability at each bulk terminal, and determines bulk 
terminal area conditions such as available product inventory, weather, etc. 
Some initial adjustments may be made, such as: arranging for additional, 

non-proprietary vehicles, deferring excess orders to later shifts or other 
bulk terminals, and specifying additional delivery restrictions for some 
orders owing to safety or other considerations. 

Finally, the complete dispatch is assembled and transmitted to the 
bulk terminal. Minor variations may be handled subsequently by the 
terminal, but any necessary major revisions are referred to the central 
dispatch facility. 
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Software and hardware difficulties attending system installation 
were expected and are now on the wane, but the workload of the central dis- 
patcher has proved to be much too high to permit the desired degree of 
aggregation of bulk terminal responsibility. Also, significant opportunities 
to reduce operating costs remain unexploited in the rather hectic dispatch 
operation. However, consistent transportation policy and control and 
enhanced customer service have proven strong impeti for development [3]. 
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3. SOLUTION SCHEME AND SUPPORTING DATA 



Our analysis of the dispatch function reveals that much of the 
time-consuming, detailed work naturally lends itself to further automation. 
However, not all details can be reasonably or economically integrated 
in an efficient manner. 

The following is a general sequence of events for these 
dispatches : 



1. Psizvtzw ofa despatch. Extract customer order and vehicle data, 
review for special cases, balance general workload, insert new 
or missing information, etc.; 

2. Compatible vzfviciz edit. Determine which vehicles can be used 
to deliver each order , considering equipment restrictions, 
compartmentation adequacy, etc. ; 

3. faAign OfidZK 6 to vzktdlU. A good dispatch minimizes operating 
costs while honoring vehicle and driver shift length restrictions; 

4. Adjust OSldZA. quantiti ^ . Order quantities may require adjustment 
to fit available vehicle compartmentation in an acceptable filling 
sequence, even for vehicles well suited to carry the load; 

5. Fiildi suZvZdiA). Identify any remaining exceptional conditions, and 
either perform minor adjustments manually or return to step 1 
with modified conditions; 
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6. TMue. cLiSpatck. Print load documents for each vehicle shift at 
the bulk terminal site, 

A critical review of this scheme was performed to identify oppor- 
tunities to reduce manual workload or improve dispatch quality. Steps 1 
and 5 heavily involve human judgment and do not invite much further auto- 
mation. Steps 2 and 4, on the other hand, are time consuming and detailed, 
yet appear to be successfully manually performed with fairly simple rules 
of thumb. Of course. Step 3 offers the most obvious new opportunity for 
outright modelling, pursued in the next section. 

Supporting data for each customer order in this idealized dispatch 
scheme include the products and quantities ordered, conditions on the degree 
of admissible adjustment in the quantities actually delivered, and delivery 
shift restrictions. In addition, each customer exhibits static data such 
as location, standard delivery time and mileage, and special delivery 
equipment requirements. 

Each vehicle is statically described in terms of operating cost 
category, compartment configuration and capacities, and special 
delivery equipment. For each shift, availability is specified; vehicles 
may be only available for a partial shift due to scheduled maintenance. 
Department of Transportation (D.O.T.) driver limitation, or other factors. 
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4. AN INTEGER PROGRAMMING FORMULATION 



This section develops and discusses an integer linear programming 
model which incorporates several of the coordination issues in a good 
dispatch, and is intended for use in Step 3 of the solution scheme. 



NOTATION 


Indices 


i 


indexes orders; 


j 


indexes trucks; 


J (i) 


index set of trucks compatible with order i. 


c . . 
ij 


GZven VaJjoi 

round-trip transportation cost of delivering order i with truck j 


t . . 

iJ 


round-trip transportation time of delivering order i with truck j 


V % 


maximum and minimum shift lengths for truck j; 


2 . , Z . 

J ~3 


penalty cost rates for violating shift length restrictions. 


y ij 


VzciAion l/<vUabl&6 

binary variable indicating whether or not order i is 
to be dispatched as a load on truck 
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Integer Linear Program 



( 1 ) 



mm 

y 



y y c,.y,, + 1 x,[s, - 1 t'-y* ■ 

1 j€J(i) 1J j J J i J lJ 



subject to 



(2) 




l 

j * J(i) 


II 

•«— ) 
•H 


i. 


all 


i 

> 




(3) 


(a) 


s . = s . 
J J 


and 


x. 

3 


= z . 
3 


when 


l t. .y . . > s . ; 
£ iJ iJ J 




(b) 


s . = s . 
J "3 


and 


x. 

J 


= z . 


when 


y t . .y . . < s . ; 
J ij 1J 




(c) 


s . = s . 
J J 


v s . 
”3 


and 


X . = 

J 


0 when 


s . < T t . .y . . < 
~3 ~ l i] iJ “ 



(4) y € {0,1} . 

Note that Che penalties satisfy z < 0 <_ by implication when s_^ < s^ 

The objective function reflects the potentially conflicting 
desire to minimize operating costs while simultaneously honoring the 
shift length restrictions. The second term penalizes any undertime, 
or overtime for truck shifts. 

Constraints (2) ensure delivery of each order as a single load. 

Specifications (3) and (4) simply enforce the desired model 
composition. 

The model was originally considered with rigid shift lengths 
(i.e., s^ = s_. and _z_. = -z = + 00 ) , expressing the widely professed 
belief that a good dispatch must utilize all equipment fully. Of course, 
no feasible solution can be guaranteed for such a formulation, as was 
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reinforced by management review of many manual dispatches. 

The model was first implemented with strict minimum and maximum 

shift lengths (i.e., s. < s . and z. = -z. = + 00 ) . This permitted 

—1 3 ~3 3 

some flexibility in assembling feasible solutions, but it required 
inordinate preview of vehicles and orders in Step 1 to insure 
feas ibility. 

Finally, the QJL&hts tC shift limits were provided as shown here. 

This formulation permits violation of shift length restrictions for 
each vehicle at a specified rate of cost. The penalty costs can be 
used to coerce prioritization of shift violations as an integral economic 
consideration. Considerable data analysis has been invested in the 
specification of these shift limits, costs, and penalties for each vehicle 
type and each shift limit rationale (e.g. D.O.T. driver limits are much 
more inflexible than simple driver overtime) . 

Note that each order has been assumed to be a full truck load. 
Although customers are urged to order this way, there are still a few 
exceptions. These are either dispatched on small trucks, or consolidated 
with small orders by the dispatcher for multiple-stop delivery. These 

LoclcIa are not easily automated since no data is currently available 
for customer-to-customer travel times and mileages, and their frequency and 
value are too small to justify the initial investment in terms of reduced 
dispatcher workload. 
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5. IMPLEMENTATION AND USE 



An elastic integer linear programming procedure and supporting data we; 
developed and improved over many months. Extensive prototype system benchmarks 
were extracted from daily operations at several bulk terminals and used to 

compare offline system results side by side with actual dispatch performance. 
The early results were very encouraging. 

Compared with manual dispatches, the system produces extremely 
uniform distribution of workload among vehicles with significantly lower 
transportation costs. For those cases in which shift limits are violated, 
the system gives the explicit economic rationale for this outcome, and 
consequently proves to have excellent face validity for dispatchers and 
management. In this respect, the system wins the competition without 
qualification. 

The benchmarks have also produced some unexpected results. Some 
rules of thumb used by manual dispatchers in Step 3 prove to be very 
uneconomical. Further, the system relentlessly reveals undetected data 
errors (a distinct advantage of optimization) that have instigated major 
internal reviews of transportation cost and time standards. Finally, it has 
become clear that some bulk terminal areas are significantly more difficult 
to dispatch well than others. For instance, it is much easier for the 
system to produce a good dispatch for a large terminal than for a small one. 

The decision to completely implement the system followed the bench- 
mark exercises. 

Unfortunately, the conditions under which the system must operate 
are rather severe. Since the dispatch system must cohabit in real time with 
a large information management system in constant use, very little pure com- 
putational power remains. Worse, the architecture of the real time 
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computer system is totally oriented to a transaction-driven software 
package. Each transaction is expected to consume minimal resources — ■ 
at most, a fraction of a second of computer time and a very small 
region. Overall performance considerations for the system do not permit 
large, heavily computational tasks to be performed without unconscionable 
delay in response time (either that for the originating dispatcher, 
or for all others using the system at the time) . Even more, transactions 
are expected to consume increments of system resources in uniform* small, and 
predictable quanta . 

This is not an ideal environment for integer programming. 

The following representative benchmark illustrates 



the situation 


. This dispatch has 28 


trucks and 103 orders , 


producing 


a model with 


611 binary variables: 






Run 


Conditions 


Solution Quality 


Solution Seconds 


i 


MPS 


unknown 


300+ 


2 


XS (Default) 


2.1% 


14 .1 


3 


XS(GUB) 


1.8% 


6.4 


4 


XS (Tuned) 


0.6% 


3.0 



Solution quality is the percentage by which the value of the integer 
incumbent exceeds the best lower bound at termination. Solution AZCOncLb 
are for IBM 3033. 
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Run 1 was performed with a connnerical optimization system, which 
had difficulty possibly related to poor enumeration tuning (not pursued). 

All subsequent runs were with our X-System, an optimization system serving 
here as an experimental testbed [2], Run 2 indicates initial performance 
with default tuning. Run 3 gives the results achieved by exploiting the 
Generalized Upper bound [4] structure of the shift-length constraints. 

Run 4 shows the best performance achieved by problem- independent tuning 
of the X-System, which requires about 100K bytes region. Runs 2-4 were 
automatically terminated when solution quality met a specified tolerance 
of, respectively, 3, 2 and 1 percent. 

This performance is not good enough for production use, especially 
with a projected workload of several hundred daily runs within a few hours 
during peak load computer conditions. 

A customized optimization system was mandated. Options considered, 
and rejected, included tailoring the general X-System for this particular 
model. The problem can be restated as a binary network assignment problem 
with gains, but the need to preserve elasticity features mitigates the 
usefulness of this observation. An alternate approach would be develop- 
ment of a network factorization algorithm [6], Both avenues were investi- 
gated, with the conclusion that very little marginal improvement in 
performance would result. Analysis of algorithm performance predicts 
that there is not a significant difference between the work performed by 
the general X-System with standard basis factorization and by a network 
variant with full elastic and integer enumeration capability. 
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6. EFFICIENT HEURISTIC WITH EMBEDDED OPTIMIZATION 



At this point, and certainly with no misplaced sense of nobility, 
a heuristic was considered. First, sheer speed is of the essence. 

Second, the problems occur with regular structure in day-to-day 
operations at each bulk terminal, providing both an opportunity to develop 
site-specific tuning and a fairly reliable method to detect misbehavior. 

Finally, the model can be fully optimized for purposes of calibration and 
selective audit by the off-line optimization system already available. 

The design of the heuristic draws from computational experience 
with the quadratic assignment model [ 7 ] and hybrids with linear programming 
[5,8] o Also, the underlying network structure (exclusive of the gains and 
attendant floating point arithmetic and basis structure) invites applica- 
tion of a puAZ neMvoAJz aZgofuXhm embedded in the heuristic. 

With this in mind, the following simple solution procedure was 
developed. A >6 zqu&ncz of embedded network problems is generated and solved with 
a variant of GNET [1]. Each such solution is used to fix of 

the orders as loads on trucks. This process is terminated when all orders 
are assigned , or when no further progress can be made. 

The generic network problem is shown in Figure 3 and described 
mathematically below. 



NOTATION 



I ndicU 



i indexes unassigned orders, only (cardinality m) ; 

j indexes trucks; 

J (i) index set of compatible trucks. 
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Given Vata 



k 
£ . 



inf’ 

t 

sup 
c! . 

ij 



denotes a dummy order (e.g., k = 0) 

total of t _ for orders already assigned as loads on truck j; 

remaining truck time projection: (z,s, - z,s,)/(z, - z.) -£ • 

~3 3 “1 J 3 

smallest, largest standard transportation times for unassigned 
orders ; 

projected, penalized transportation cost; 






c . . = - 



c . . 
ij 






1 + lT./t. 

3 mf 



.) 


if 




T ,-T . . 


< 


0 








3 1 3 






\ .) 


if 


0 < 


t . “T . . 


< 


T 


1 3 






J 1 3 




sup 




T. ) if 


T /0 < 


T ,-T 


< 


T 


ij 


mf 


sup/ 2 


3 ij 




inf 




if 


T . _ < 


T -X 










mf 


3 ij 






still 


as sign ab le 


to truck 


j : 








if t 


a > 0 , 









otherwise ; 






range of the number of orders still assignable to truck j 



u . . = 



b . - It ./t 
3 J sup 



if x . > 0 , 
J 



otherwise ; 



total excess (unassignable) orders: Y b - m 

j j 
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VzdiAZon Va/vLablzA 



y.j variable indicating whether or not order i is preferred as a 

load on truck j ; 

4 variable indicating estimated surplus loads preferred for truck j . 
Embedded Network 



( 1 ) 



(2) (sources) 



min 7 / c ! v . . 

y i jU(i) ^ 



subject to 



l y,, £ 1 . all i; 

j€j(i) 1J 

I 4. < d ; 
j 



(3) (sinks) 



-4 . - 7 y . . = -b . 

J J ij J 



all j ; 



(4) y € (0,1) , all i, j ; 

4. € {0 ,1 , . . . ,u.} , all j, 

J J 

The units of this pure network formulation are increments of 
time approximately equal to the standard delivery time of the shortest 
remaining unassigned order. The formulation assumes that all unassigned 
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orders require this time increment for delivery and that remaining truck 
time is always some integral multiple of this time increment. The objective 
function reflects the projected consequence of assigning any remaining 
order to a truck. Many options are available in forming this objective. 
Shown here is one approach with four cases for c^ respectively represent- 
ing: 1) certain overload, 2) small underload for which no other order 

is likely to fit, 3) underload for which at least one other order might 
fit as well and 4) extreme underload. This objective is chosen in concert 
with the one-pass, non-backtracking fixing scheme shown below. 

Each network solution is examined and orders are fixed as loads 

on trucks as follows. For each truck, if any orders have been assigned 

by the network solution, and if the assigned order with the longest delivery 

time does not create a worse total time penalty for that truck, fix that 

order and update the projected remaining truck time x . Continue fixing 

orders for that truck until x. < T (t. + t ) (e.g., T = 2 , a heuristic 

j inf sup & 

parameter) . When this condition is met, repeat the process for the next 
truck. 

If at least one order is fixed for some truck, continue the 
heuristic with another (smaller) network problem. 

When no order is assigned, the embedded network iteration ceases 
and any remaining unassigned orders are placed on a bpUUL LL&£. This 
list can include other orders orphaned by the compatibility edit in Step 2, 
and is treated as a phantom truck with transportation costs equivalent to 
the preferred short-term non-proprietary truck type for the local bulk 
terminal . 
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SOURCES 



SINKS 




I Unassigned \ 
\ Orders, i / 



( Trucks , j j 



FIGURE 3. Embedded Network 
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Next, the overall solution is improved if possible by simple 
pairwise comparisons and AulitehZA of loads between compatible trucks, 
or of loads from one truck to another. Higher order exchanges are 

not used. 

Following the fixing of orders as loads on trucks, the order 
quantities are adjusted for each load in Step 4 to best suit the truck 
compartment ation. This typically involves assigning 3 products to 6 
compartments. Each compartment is filled to its precise product-specific 
capacity, which is a function of temperature-corrected product density. 

An enumeration scheme is used which determines which permutation 
of product- to-compartment assignments is most desirable. No adjustment 

is considered which completely eliminates a product. For each product, 
an "up" and "down" adjustment penalty is specified. For each load, 
ordered quantities of component products may also be coded with an 
additional penalty representing varying degrees of inflexibility. Two 
optimal compartment sequences are determined on the basis of total quantity 

adjustment penalty, one with adjacent compartments for each product 
and one with no adjacency restrictions. The contiguous load sequence is 
selected unless the companion sequence is significantly better by a constant 
specified by the dispatcher. 

This scheme gives the dispatcher the capability to influence several 
overall factors for each bulk terminal. Quantity adjustments can be 
controlled in keeping with product supplies (especially shortages) so that 
customers are still equitably served. Contiguous product sequences are 
desirable because of the reduced driver workload at the loading rack 
and the customer site. 
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The success of the order quantity adjustment in Step 4 is highly 
dependent upon the compatible vehicle edit in Step 2, which restricts 
candidate vehicles for each order. On the other hand, to the degree that 
Step 2 is increasingly selective in screening compatible vehicles, the 
potential transportation cost savings of Step 3 are reduced. Balancing 

these effects, Step 2 is a compromise which is suggested by examining 
manual dispatch procedures. 

The compatible vehicle edit of Step 2 examines each order with 
respect to all candidate vehicles indicated feasible for delivery. 

Initially, candidates are ruledoat for obvious reasons (e.g., fewer compartments 
than products ordered) . 

At this point, Step 2 could be patterned after the quantity 
adjustment in SteD 4, evaluating for each candidate vehicle the most 
desirable compartment sequence to fit the order as a load, and editing vehicles 
with respect to a maximum permissible adjustment threshold. This 
approach is prohibitively expensive when applied to dtt candidate 
vehicles for each load. 

Instead, a simple heuristic is used. Each candidate vehicle 
is ruled out if its £4 timatzd capacity is sufficiently close to the total 
order quantity. (Recall that CIcXuaZ capacity is a function of product assign- 
ments to compartments.) Capacity is estimated by assuming that the entire 
order consists of the product with the largest order quantity, and "up" 
and "down" adjustment limits supplied by the dispatcher for each bulk 
terminal are applied. Next, if the 5 maJULzbt product order quantity is 
below a given volume, it is fit to the closest compartment on the candidate 
truck, and the truck is ruled out if the required adjustment is above 
specified limits. 
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Steps 2, 3, and 4 can each be overridden by the dispatcher, 
who can specify compatible vehicles, fix loads, and assign compartments 
as he sees fit during the dispatch. This is especially useful for multiple 
iterations of these steps. 

The various parameters, penalties and limits of these procedures 
are specified for each bulk terminal. They are designed for easy 
comprehension and use by dispatchers in controlling the automated dispatch 
module, adapting to special local conditions, and responding to overall 
judgment on dispatch quality. 

For the representative test problem cited earlier in this section, 
the dispatch module requires 61K bytes and 0.2 compute second for the 
heuristic solution to the integer model in Step 3. Step 2 
requires 0.1 second to edit compatible trucks and Step 4 requires 0.2 
second to adjust order quantities. 

The contracting network sequence in Step 3 requires a total 
of 5 steps, respectively with 611, 302, 154, 71 and 14 unassigned orders. 

The solution quality, compared to the earlier known bounds, is 0.5%. 

These results are very typical. 

Solution quality can also be compared with bounds developed with- 
out optimization directly from problem data. For instance, if each order 
is assigned as a load on the cheapest (or most expensive) compatible 
truck, lower (or upper) bounds are derived for total transportation 
costs. With respect to this lower bound, the solution cited has quality 1.0%. 

Many other performance measures are easily applied without resort- 
ing to outright optimization. For instance, an ideal economic fleet 
configuration is derived with and without compatibility restrictions 
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and used to evaluate truck selection, configuration and placement. To 
monitor the effects of conditions imposed on customer orders, and to 
reveal systematic errors in transportation cost and delivery time estimates. 

After many thousands of production runs and numerous minor adjust- 
ments, the dispatch module produces excellent solution quality and face 
validity with extremely reliable performance and high efficiency. In 
fact, many dispatches no longer require any adjustment or reruns at the 
final review. Step 5. 
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7. CONCLUSION 



This project has provided many valuable lessons for both the managers 
and management scientists involved. The most fundamental decisions concern 
neither models nor implementation details. The crucial analysis focuses 
on what should and what should not be automated, and on how much 
compromise of reality is desirable in the automated portions of the 
system. 

The environment for this particular work — a congested computer system, 
peak production workload, and capacitated personnel — has given an excellent 
aggregate means of evaluating results. The system would either provide 
better overall productivity, or fail completely. Fortunately, the quality, 
economy, efficiency, and face validity of the semi-automated dispatch solutions 
have been excellent, and the project is successful. 

Individual productivity is increased only to the degree that the 
dispatcher still controls, understands, and accepts the automated modules. 

Most important, human judgement must be introduced naturally in such semi- 
automated systems to cope with extraordinary conditions. The total cost 
of automating responses to exceptional circumstances extends far beyond 
the solution modules in the host organization, and can render an otherwise 
desirable system totally infeasible. 

! 

From the perspective of contemporary management support systems, there 
are continually increasing opportunities to apply optimization. However, 
classical optimization systems and techniques are rarely designed for 
use in the demanding, real-time environment so common to pervasive informa- 
tion management systems. Enforcing a monadic view of optimization, 
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especially for combinatorial problems, reveals weaknesses not con- 
templated before by designers of stand-alone algorithms and systems. 

For this particular problem, the environment and implementation schedule 
has mandated the use of heuristic methods. Heuristics are usually based 
on repeated applications of simple functions (such as sorting), just 
as they are often patterned after concepts useful in productive reasoning 
(such as greed). Fortunately, the remarkable efficiency of minimum cost 
network algorithms has recently made this class of model also available as such a 
routine tool. Methods employing nested sequences of conditional network 
problems show much promise for a wide range of combinatorial models, 
especially for those with embedded network structure such as the quadratic 
assigment model. Better yet, such use of embedded optimization forces 
a design discipline which may help make these methods much more desirable 
for timely use on important management issues. 

As for solution quality, heuristics have a well deserved reputation 
for unreliability. However, there are appropriate arenas for heuristic 
methods, especially if bounds can be developed for objective assessment of 
solutions. Bounded heuristics can serve admirably, reliably extracting 
much of the information that an algorithm would provide and producing 
solutions whose repetitive nature and audited error distribution can be 
shown to yield reasonably good results. 
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